Thorsten Froehlich wrote:

>> Correct. But all as you normally need to have all template stuff
>> inline, this results in a lot of inline code duplication.
> 
> No, only the very common bad programming habit of placing template
> implementation code inside classes instead outside causes template code to
> be inlined (also a compiler is *not* required to inline anything!).
> 
(Yes but good compilers do when told so...)

>> Because the C construction does no reference counting. You allocate
>> a pointer once and then use it. And the designer knows where it was
>> allocated, "who" is responsible for the pointer and its lifetime.
>>
>> Yes, that's insecure like hell but faster and smaller.
> 
> Of course, nothing keeps you from doing this in C++ as well...
> 
We were talking about what is faster... and what safer...

>> That will (1) allocate some bytes on the stack (fast) and then
>> (2) allocate internal object using operator new (slow).
>>
>> That is what I had in mind.
> 
> I almost assumed you did.  However, node that having just a pointer to an
> "internal" object is just terrible design, and if you use this to hide
> something "private" behind another interface, C++ is not the language you
> want to be using!
> 
Ah really?! Have fun reading the STL code :p

> Second, if you really have a valid need to frequently create temporary
> copies of a specific class of objects, you will gain a really lot if you
> use
> a memory pool (i.e. boost::pool for C++). 
>
I tried things like that. Stack allocation is still fastest for 
small amounts of memory. 

> And of course, you will still
> have the same problems when doing something similar in C.
>
One would not use a desing like that in plain C. 
 
>> I still am the opinion that it is pretty hard if not (nearly?) impossible
>> to design really fast C++ code (i.e. as fast as insecure C code) when one
>> forces itself to stick to all the "good style" guidelines. (Depends on
>> what one defines as "good style").
> 
> Yet, but you are making two major mistakes in your logic here: Just
> because C++ allows you to use more secure programming methods does not
> imply in any
> way that C++ is slow or slower than C.  It simply implies that a
> well-programmed piece of code will have a tiny bit of overhead over a fast
> hack. 
>
I was making no mistake in my reasoning. I just wanted to express 
what you stated above in your own words...
No discrepancy there. 

> And the languages features for good programming style only exist in
> C++ but not C.  Thus you can only use them in C++, while you are stuck
> with unstable code in C.
> 
You could implement similar (not-so-safe) things in C. Don't understand 
me wrong: 
I do _not_ propose that, it's just what I extracted from your frequent 
replies stating "you would have the same overhead in C when implementing 
that in C". 

> However, this is the case for any higher language level.  You can claim
> exactly the same for C and your native assembler.  Of course, if you know
> what you are doing you can still outperform even a very good compiler (the
> SSE2 noise code in POV-Ray is a good example for this) by using lower
> level programming languages, but that doesn't say anything about the
> higher level languages!
> 
Correct. Assuming that one could implement the core parts of an 
application in assembler gaining speed increases of factor 2 or above 
it may seem irrelevant to talk about <=5% loss at a C -> C++ transition. 
Especially if there are benifits (better maintainability, etc)

Wolfgang

Post a reply to this message